多种|抽象性_4种主流的API架构风格对比

篇首语：本文由编程笔记#小编为大家整理，主要介绍了4 种主流的 API 架构风格对比相关的知识，希望对你有一定的参考价值。

RPC 使用 GET 来获取信息，使用 POST 来处理其他所有操作。服务端和客户端之间交互的机制归结为调用端点并获得响应。

易于添加新函数。 如果 API 有了新的需求，我们可以轻松地添加另一个执行这个需求的端点：1）编写一个新函数，并将其放在一个新端点之后；2）现在，客户可以访问这个端点，并获取符合其需求的信息。

高性能。 轻量级的有效负载不会对网络产生压力，以此提供高性能，这对于共享服务器和在工作站网络上执行并行计算非常重要。RPC 还能够优化网络层，使得不同服务之间每天发送海量消息变得非常高效。

内置创建 Web 服务的功能使得 SOAP 能够处理消息通信的同时发送独立于语言和平台响应。

绑定到各种协议。 SOAP 在适用于多种场景的传输协议方面是十分灵活的。

内置错误处理。 SOAP API 规范允许返回带有错误码及其说明的的 XML 重试消息。

一系列的安全拓展。 SOAP 与 ES-Security 集成，因此 SOAP 可满足企业级事务要求。它在事务内部提供了隐私和完整性，同时允许在消息级别进行加密。

SOAP 消息包含大量的元数据，并且在请求和响应时仅支持繁冗的 XML 格式。

重量级。 由于 XML 文件的大小，SOAP 服务需要很大的带宽。

非常专业化的知识。 构建 SOAP API 服务器需要对所有涉及到的协议以及它们及其严格的限制都有很深的了解。

乏味的消息更新。 由于需要额外的工作来添加或者删除某个消息属性，这种死板的 SOAP 模式减慢了其被采用的速度。

由于 REST 尽可能地解耦了客户端和服务端，REST 相较于 RPC 可以提供更好的抽象性。具有抽象级别的系统能够封装其实现细节，以更好的标示和维持它的属性。这使得 REST API 足够灵活，可以随着时间的推移而发展，同时保持稳定的系统。

可发现性： 客户端和服务端之间的通信描述了所有内容，因此不需要外部文档即可了解如何与 REST API 进行交互。

缓存友好： REST 重用了许多 HTTP 工具，也是唯一一种可以在 HTTP 层面上缓存数据的 API 架构风格。与其相对的是，在任何其他 API 上实现缓存都需要配置其他缓存模块。

多种格式支持： REST 拥有支持多种格式用于存储和交换数据的能力，这是它如今成为搭建公共 API 的主要选择的原因之一。

在用于连接不需要查询灵活性的资源驱动型应用时，REST 是一种非常有效的方法。

GraphQL 提前公开了它能做什么，从而提高了其可发现性。通过将客户端指向 GraphQL API，我们可以发现什么查询语句是可用的。

没有版本控制： 版本控制的最佳实践是不要对 API 进行版本控制。

尽管 REST 提供了不同的 API 版本，GraphQL 使用的是不断更新的单一版本，这使用户可以持续访问新功能，并有助于提供更整洁、更可维护的服务器代码。

详细的错误消息： GraphQL 以类似于 SOAP 的方式提供所发生错误的详细信息。它的错误消息包括所有解析器，并指向确切的发生故障时的查询部分。

灵活的权限： GraphQL 允许选择性地公开某些功能，同时保留私人信息。而相对应的是，REST 体系架构不能仅显示部分数据，要么是全部数据，要么是没有数据。

GraphQL 权衡了复杂性，来实现其强大功能。一个请求中的嵌套字段太多会导致系统过载。因此，对于复杂的查询，REST 仍然是更好的选择。

缓存复杂度。 由于 GraphQL 不再使用 HTTP 缓存语义，因此使用者需要额外自定义缓存。

大量的预开发教育。 由于没有足够的时间来了解 GraphQL 的某个操作和 SDL，因此许多项目决定采用众所周知的 REST 方法。

在这种情况下，网络性能和单个消息有效负载优化很重要。因此，GraphQL 为移动设备提供了更有效的数据加载方式。

复杂的系统和微服务。 GraphQL 能够隐藏其 API 背后的多个系统集成的复杂性。GraphQL 从多个地方聚合数据，并将它们合并为一个全局的模式。对于随时间推移而逐渐扩展的遗留基础架构或第三方 API 来说，这尤其重要。

5.哪种 API 模式最适用你的用例？

每个 API 项目都有不同的限制和需求。通常，API 架构的选择取决于：

所使用的编程语言，

你的开发环境，以及

你的资源预算，包括人力资源和财务资源。

在了解了每种设计风格的利与弊之后，API 设计人员可以选择最适合项目的那一种。

具有强耦合性的 RPC 很适用于内部微服务，但它对外部 API 或者 API 服务而言不是一个好的选择。

SOAP 的使用有些麻烦，但它强大的安全拓展使它在计费操作、预订系统和支付方面是无可替代的。

REST 是针对 API 的最高级别的抽象和最佳模型。但它往往会有些“啰嗦”而增加系统的负担 —— 如果你使用的是移动设备，这是个问题。

GraphQL 在数据获取方面向前迈出了一大步，但并不是每个人都有足够的时间后精力来掌握它。

归根结底，去针对一些小型的用例来尝试某种特定 API 架构，并去了解它是否适合你的用例以及是否解决了你的问题，这样做是比较合适的。如果它适用于你的用例，就可以尝试扩展并查看它是否适用于更多的用例。

来源：infoQ

推荐：

主流Java进阶技术（学习资料分享）

PS：因为公众号平台更改了推送规则，如果不想错过内容，记得读完点一下“在看”，加个“星标”，这样每次新文章推送才会第一时间出现在你的订阅列表里。点“在看”支持我们吧！